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Abstract 
This document allocates the fixed pseudowire identifier and other 
fixed protocol values for protocols that have been defined in the 


Pseudo Wire Edge to Edge (PWE3) working group. Detailed IANA 
allocation instructions are also included in this document. 
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1. Introduction 


Most of the new IANA registries and respective IANA-allocation 
processes for protocols defined in the PWE3 IETF working group can be 
found in this document. The IANA registries defined here are in 
general subdivided into three main ranges: a range to be allocated by 
IETF consensus according to [RFC2434], a range to be allocated by the 
expert review process according to [RFC2434], and a range to be 
allocated on a first come, first served basis that is reserved for 
vendor proprietary allocations. Note that vendor proprietary types 
MUST NOT be registered for IETF standards or extensions thereof, 
whether they are still in development or already completed. 


2. Specification of Requirements 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


3. IANA Considerations 


TANA has created several registries as described in the following 
paragraphs. Each of these registries contains numeric values used to 
identify data types. In each of these registries, the value of 0 is 
reserved and MUST not be used. 


3.1. Expert Review Directives 
Throughout this document, allocation procedures for several 
registries call for an expert review process according to [RFC2434]. 
The expert should consider the following points: 


* Duplication of code point allocations should be avoided. 


* A brief, clear description of the code point allocation 
requested should be provided. 


* The type allocation requested should be appropriate for the 
particular requested value range in the registry. 


The expert reviewing the request MUST approve or disapprove the 


request within 10 business days from when he or she received the 
expert review request. 
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3.2. MPLS Pseudowire Type 


IANA has set up the registry of "MPLS Pseudowire Type". This type 
has 15-bit values. PW Type values 1 through 30 are specified in this 
document, and PW Type values 31 through 1024 are to be assigned by 


IANA, using the "Expert Review" policy defined in [RFC2434]. PW Type 
values 1025 through 4096 and 32767 are to be allocated using the IETF 
consensus policy defined in [RFC2434]. PW Type values 4097 through 


32766 are reserved for vendor-proprietary extensions and are to be 
assigned by IANA, using the "First Come First Served" policy defined 
in [RFC2434]. A Pseudowire Type description is required for any 
assignment from this registry. Additionally, for the vendor- 
proprietary extensions range, a citation of a person or company name 
is also required. A document reference should also be provided. 


Initial Pseudowire Type value allocations are specified below: 


PW type Description Reference 
0x0001 Frame Relay DLCI ( Martini Mode ) [FRAME ] 
0x0002 ATM AAL5 SDU VCC transport [ATM] 
0x0003 ATM transparent cell transport [ATM] 
0x0004 Ethernet Tagged Mode [ETH] 
0x0005 Ethernet [ETH] 
0x0006 HDLC [PPPHDLC] 
0x0007 PPP [PPPHDLC] 
0x0008 SONET/SDH Circuit Emulation Service Over MPLS [CEP] 
0x0009 ATM n-to-one VCC cell transport [ATM] 
Ox000A ATM n-to-one VPC cell transport [ATM] 
0x000B IP Layer2 Transport [RFC3032] 
0x000C ATM one-to-one VCC Cell Mode [ATM] 
0x000D ATM one-to-one VPC Cell Mode [ATM] 
OxO000E ATM AAL5 PDU VCC transport [ATM] 
0x000F Frame-Relay Port mode [FRAME ] 
0x0010 SONET/SDH Circuit Emulation over Packet [CEP] 
0x0011 Structure-agnostic El over Packet [SATOP] 
0x0012 Structure-agnostic T1 (DS1) over Packet [SATOP] 
0x0013 Structure-agnostic E3 over Packet [SATOP] 
0x0014 Structure-agnostic T3 (DS3) over Packet [SATOP] 
0x0015 CESoPSN basic mode [CESOPSN] 
0x0016 TDMoIP AAL1 Mode [TDMoIP] 
0x0017 CESoPSN TDM with CAS [CESOPSN] 
0x0018 TDMoIP AAL2 Mode [TDMoIP] 
0x0019 Frame Relay DLCI [FRAME] 
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.3. Interface Parameters Sub-TLV Type 


IANA has to set up the registry of "Pseudowire Interface Parameter 
Sub-TLV types". This type has 8-bit values. Sub-TLV types 1 through 
12 are specified in this document. Sub-TLV types 13 through 64 are 
to be assigned by IANA, using the "Expert Review" policy defined in 
[RFC2434]. Sub-TLV types 65 through 127 and 255 are to be allocated 
using the IETF consensus policy defined in [RFC2434]. Sub-TLV types 
values 128 through 254 are reserved for vendor-proprietary extensions 
and are to be assigned by IANA, using the "First Come First Served" 
policy defined in [RFC2434]. 


Any assignments requested from this registry require a description of 
up to 54 characters. 


For each allocation, a length field MUST also be specified in one of 
the following formats: 


- Text as follows:"up to X", where X is a decimal integer. 
- Up to 3 different decimal integers. 


The text "up to X" means up to and including X. 
Additionally, for the vendor-proprietary extensions range, a citation 
of a person or company name is also required. A document reference 


should also be provided. 


Initial Pseudowire Interface Parameter Sub-TLV type allocations are 
specified below: 


Parameter Length Description Reference 
ID 
0x01 4 Interface MTU in octets [CRTL] 
0x02 4 Maximum Number of concatenated ATM cells [ATM] 
0x03 up to 82 Optional Interface Description string [CRTL] [RFC2277] 
0x04 4 CEP/TDM Payload Bytes [CEP] [TDMoIP] 
0x05 4 CEP options [CEP] 
0x06 4 Requested VLAN ID [ETH] 
0x07 6 CEP/TDM bit-rate [CEP] [TDMoIP] 
0x08 4 Frame-Relay DLCI Length [FRAME] 
0x09 4 Fragmentation indicator [FRAG] 
Ox0A 4 FCS retention indicator [FCS] 
0x0B 4/8/12 TDM options [TDMoIP] 
0x0C 4 VCCV parameter [VCCV] 


Note that the Length field is defined as the length of the Sub-TLV, 


including the Sub-TLV type and length field itself. 
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3.4. Attachment Identifiers 
3.4.1. Attachment Individual Identifier Type 


IANA has to set up the registry of "Attachment Individual Identifier 
(AII) Type". This type has 8-bit values. AII Type value 1 is 
defined in this document. AII Type values 2 through 64 are to be 
assigned by IANA, using the "Expert Review" policy defined in 
[RFC2434]. AII Type values 65 through 127 and 255 are to be 
allocated using the IETF consensus policy defined in [RFC2434]. AII 
types values 128 through 254 are reserved for vendor-proprietary 
extensions and are to be assigned by IANA, using the "First Come 
First Served" policy defined in [RFC2434]. 


Any assignments requested from this registry require a description of 
up to 54 characters. 


For each allocation, a length field MUST also be specified as a 
decimal integer. 


Additionally, for the vendor-proprietary extensions range, a citation 
of a person or company name is also required. A document reference 
should also be provided. 


Initial Attachment Individual Identifier (AII) Type allocations are 
specified below: 


AII Type Length Description Reference 
0x01 4 A 32 bit unsigned number local [SIG] 
identifier. 


3.4.2. Attachment Group Identifier (AGI) Type 


IANA has to set up the registry of "Attachment Group Identifier (AGI) 
Type". This type has 8-bit values. AGI Type value 1 is defined in 
this document. AGI Type values 2 through 64 are to be assigned by 
IANA, using the "Expert Review" policy defined in [RFC2434]. AGI 
Type values 65 through 127 and 255 are to be allocated using the IETF 
consensus policy defined in [RFC2434]. AGI type values 128 through 
254 are reserved for vendor-proprietary extensions and are to be 
assigned by IANA, using the "First Come First Served" policy defined 
in [RFC2434]. 


Any assignments requested from this registry require a description of 
up to 54 characters. 
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For each allocation, a length field MUST also be specified as a 
decimal integer. 


Additionally, for the vendor-proprietary extensions range, a citation 
of a person or company name is also required. A document reference 
should also be provided. 


Initial Attachment Group Identifier (AGI) Type allocations are 
specified below: 


AGI Type Length Description Reference 
0x01 8 AGI encoded as Route Distinguisher [SIG] 
3.5. Pseudowire Status 
IANA has to set up the registry of "Pseudowire Status Codes". These 


are bit strings of length 32. Status bits 0 through 4 are defined in 
this document. Status bits 5 through 31 are to be assigned by IANA 
using the "Expert Review" policy defined in [RFC2434]. 


Any requests for allocation from this registry require a description 
of up to 65 characters. 


Initial Pseudowire Status Code value allocations are as follows: 


Bit Mask Description 
0x00000000 - Pseudowire forwarding (clear all failures) [CRTL] 
0x00000001 - Pseudowire Not Forwarding [CRTL] 


0x00000002 - Local Attachment Circuit (ingress) Receive Fault [CRTL] 
0x00000004 - Local Attachment Circuit (egress) Transmit Fault [CRTL] 
0x00000008 - Local PSN-facing PW (ingress) Receive Fault [CRTL] 
0x00000010 - Local PSN-facing PW (egress) Transmit Fault [CRTL] 


For the definition of the "PW Associated Channel Type" please refer 
to [RFC4385]. 


3.6 PW Associated Channel Type 


For the definition of the "PW Associated Channel Type", please refer 
to [RFC4385]. 
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4. Security Considerations 


This document specifies only fixed identifiers, and not the protocols 
used to carry the encapsulated packets across the network. Each such 
protocol may have its own set of security issues, but those issues 
are not affected by the identifiers specified herein. 
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This document is subject to the rights, licenses and restrictions 
contained in BCP 78, and except as set forth therein, the authors 
retain all their rights. 
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